1. Field of the invention
Methods, systems, and computer-readable mediums consistent with the present invention relate to a virtual machine. More particularly, the present invention relates to interpreting a method bytecode in operation of a virtual machine.
2. Description of the Prior Art
JAVA is an object-oriented programming language developed by Sun Microsystems, Inc. and is defined by the JAVA language standard.
The JAVA virtual machine standard defines a model that can independently execute a JAVA program expressed through an instruction set called bytecode, in a platform.
Bytecode can be generated by a JAVA language compiler that converts a program expressed by a JAVA language.
A JAVA virtual machine executes a predetermined operation by interpreting the bytecode. Such execution of the JAVA virtual machine consumes a small-space resource such as a memory due to the compactness of the bytecode.
However, the performance of the interpreted bytecode becomes lower than that of a program compiled by a native language that can be interpreted directly by a system.
Accordingly, a trade-off between the space required for the execution and the performance attracts attention in development of the JAVA virtual machine. In particular, such a trade-off attracts much attention in development of the JAVA virtual machine based on a platform having a small hardware resource such as an embedded system.
The current trend for improving the performance of the JAVA virtual machine is to provide a compiler that converts a JAVA bytecode into a native code to reduce overhead caused by interpretation of bytecode.
However, since the native code of recent hardware architecture requires a memory space greater than the bytecode, an interpreter is still used if there is limitation in the memory space.
In general, the interpreter has a loop type structure such as “while” statement.
According to “HotSpot JavaVM” technique of Sun Microsystems, Inc. an interpreter loop is generated only once when the operation of the virtual machine starts, i.e., at a time point of “start-up.” In this case, as the use of a cache is reduced (cache flush frequently occurs), the performance of the interpreter loop is reduced. In particular, since a smaller processor cache is used for a present embedded architecture, it is more likely that the performance of the interpreter loop is reduced.
Furthermore, according to the prior art, a single interpreter loop is generated before the “VM-build.” In this case, since the interpreter loop is dependent upon a specified application known in advance, a problem is caused if another application is loaded.
Meanwhile, U.S. Patent Publication No. 2004-0088703 discloses a method of generating an interpreter having hierarchical loops, as shown in FIG. 1.
First, among bytecodes to be processed by an interpreter, bytecodes frequently executed are identified (S110), and bytecodes not frequently executed are identified (S120).
Afterwards, bytecodes that are simple to execute and bytecodes that are difficult to execute are identified (S130).
If the bytecodes are identified as above, a first interpreter loop is generated to process the bytecodes that are simple to execute and that are frequently executed (S140), and a second interpreter loop is generated to process the other bytecodes (S150).
In other words, not only one interpreter loop but also hierarchical interpreter loops are formed considering the characteristics of the bytecodes. A pseudo-code that executes the bytecodes by using the interpreter having two loops in accordance with the method of FIG. 1 is shown in FIG. 2. However, since the interpreter loops are generated before the “VM-build,” there is a problem with dynamically loaded applications.